System and method for image localization in knowledge base content

ABSTRACT

An information handling system includes a memory device and a processor. The processor instantiates a knowledge base that includes knowledge base information arranged into a parent image locale (PIL) that includes a parent image that presents a portion of the knowledge base information in a first language. The processor translates the knowledge base information into a second language. In translating, the processor further determines that the knowledge base information has previously been translated into the second language based upon the knowledge base information being further arranged into a child image locale (CIL) that includes a child image that presents the portion of the knowledge base information in the second language, and replaces the child image with the parent image in the CIL when a first date when the parent image was modified is later than a second date when the child image was modified.

FIELD OF THE DISCLOSURE

This disclosure generally relates to information handling systems, andmore particularly relates to managing image localization in knowledgebase content.

BACKGROUND

As the value and use of information continues to increase, individualsand businesses seek additional ways to process and store information.One option is an information handling system. An information handlingsystem generally processes, compiles, stores, and/or communicatesinformation or data for business, personal, or other purposes. Becausetechnology and information handling needs and requirements may varybetween different applications, information handling systems may alsovary regarding what information is handled, how the information ishandled, how much information is processed, stored, or communicated, andhow quickly and efficiently the information may be processed, stored, orcommunicated. The variations in information handling systems allow forinformation handling systems to be general or configured for a specificuser or specific use such as financial transaction processing,reservations, enterprise data storage, or global communications. Inaddition, information handling systems may include a variety of hardwareand software resources that may be configured to process, store, andcommunicate information and may include one or more computer systems,data storage systems, and networking systems.

SUMMARY

An information handling system may instantiate a knowledge base havingknowledge base information arranged into a parent image locale (PIL)that includes a parent image that presents a portion of the knowledgebase information in a first language. The system may further translatethe knowledge base information into a second language. In translating,the system may further determine that the knowledge base information haspreviously been translated into the second language based upon theknowledge base information being further arranged into a child imagelocale (CIL) that includes a child image that presents the portion ofthe knowledge base information in the second language, and replace thechild image with the parent image in the CIL when a first date when theparent image was modified is later than a second date when the childimage was modified.

BRIEF DESCRIPTION OF THE DRAWINGS

It will be appreciated that for simplicity and clarity of illustration,elements illustrated in the Figures have not necessarily been drawn toscale. For example, the dimensions of some of the elements areexaggerated relative to other elements. Embodiments incorporatingteachings of the present disclosure are shown and described with respectto the drawings presented herein, in which:

FIG. 1 is an illustration of a knowledge base according to an embodimentof the current disclosure;

FIG. 2 is an illustration of image files in the knowledge base of FIG. 1;

FIG. 3 is a block diagram of a knowledge base translator for translatingarticles in the knowledge base of FIG. 1 ;

FIG. 4 is a flowchart illustrating a method for creating images in aknowledge base according to an embodiment of the current disclosure;

FIG. 5 is a flowchart illustrating a method for updating a knowledgebase according to an embodiment of the current disclosure; and

FIG. 6 is a block diagram illustrating a generalized informationhandling system according to another embodiment of the presentdisclosure.

The use of the same reference symbols in different drawings indicatessimilar or identical items.

DETAILED DESCRIPTION OF DRAWINGS

The following description in combination with the Figures is provided toassist in understanding the teachings disclosed herein. The followingdiscussion will focus on specific implementations and embodiments of theteachings. This focus is provided to assist in describing the teachings,and should not be interpreted as a limitation on the scope orapplicability of the teachings. However, other teachings can certainlybe used in this application. The teachings can also be used in otherapplications, and with several different types of architectures, such asdistributed computing architectures, client/server architectures, ormiddleware server architectures and associated resources.

FIG. 1 illustrates a knowledge base 100 including a number of articles110. Knowledge base 100 represents a collection of information about aparticular subject area or group of related subjects, that is organizedand curated in a way to make the information more accessible and usableto clients of a knowledge base system. Here, a knowledge base system maybe understood as computer hardware and the software that operates on thecomputer hardware to create, monitor, maintain, and edit the informationincluded in knowledge base 100. The knowledge system may further beunderstood to provide mechanisms for ease of access to the informationincluded in knowledge base 100. Thus, as used herein, the “knowledgebase” will be understood to refer to the information that is stored inand manipulated by the “knowledge base system.” The functions of aknowledge base system in creating, monitoring, maintaining, and editingthe information of a knowledge base and for providing access to theinformation of the knowledge base are known in the art and will not befurther described herein, except as needed to illustrate the currentembodiments.

Articles 110 each represent a collection of information that is relatedto a common subject area, and that is organized to be accessed by theclients. Each article 110 includes content items that encapsulate theinformation of the article. In the simplest case, an article 110 willinclude content that is created, monitored, maintained, and edited in,and provided for access by a single language. In this case, the contentitems will be organized and structured as a parent locale (PL) 120 ofarticle 110. PL 120 includes various content objects that are organizedto be presented in a logical order and to make a presentation of theinformation included therein. For the purpose of the present disclosure,the contents objects will be represented as text files and image files.As such, PL 120 includes a parent text locale (PTL) 122 that includesone or more text files 124 in the parent language, and a parent imagelocale (PIL) 126 that includes one or more image files 128 that may ormay not include text in the parent language.

In the more generalized case, article 110 will include content that iscreated, monitored, maintained, and edited in, and provided for accessby one or more additional language. In this case, the content items willbe further organized and structured as one or more child locale (CL) 130of the article. CL 130 includes various content objects that areorganized to be presented in a logical order and to make a presentationof the information included therein, and the organization typicallymirrors the organization of the associated PL 120. As such, CL 130includes a child text locale (CTL) 132 that includes one or more textfiles 134 in the child language, and a child image locale 136 thatincludes one or more image files 138 that may or may not include text inthe child language.

Here, the term “text file” will be understood broadly to include filesand formats that cover a wide range of textual content, and should notbe construed narrowly to content items that are exclusively text based.For example, text file 124 may include simple text content, such as SMSmessages, .TXT files, notebook files, and the like, processed text-basedcontents such as word processing files, databases, spreadsheets,presentations, and the like, or more specialized content that embedstext objects within a larger file format, such as HyperText (HTTP)files, XML files, and the like, or other file types that include textualinformation, as needed or desired. Further, the term “image file” willbe understood broadly to include files and formats that cover a widerange of visual content, and should not be construed narrowly to contentitems that are exclusively picture based. For example, image file 128may include simple image content, such as JIF files, bitmap files, .jpgfiles, TIFF files, and the like, video content files, such as .avifiles, .mpg files, .mp4 files, and the like, or other types of visualcontent, as needed or desired. Further, one or more of text file orimage file may be understood to include audio content, as needed ordesired. It may further be so that the types of content stored in PTL122 or CTL 132, and the types of content stored in PIL 126 or CIL 136,may have significant overlap, and the particular organization of theinformation in PL 120 and CL 130 will be determined based upon the needsor desires of the particular design or knowledge base designer. Thus,the details of organizing information in a knowledge base article areknown in the art and will not be further described herein, except asneeded to illustrate the current embodiments.

Historically, the translation from PL 120 to the one or more CLs 130 wasperformed manually, with each text file 124 being manually translated toa corresponding text file 134. Similarly, each image file 128 thatincluded text being would be manually translated, or “re-shot” in thetranslated language to provide a corresponding image file 138. Forexample, where article 110 included information describing the operationand manipulation of a user interface (UI), the translation of text filesfrom text file 124 to text file 134 was a straight forward translationtask. On the other hand, an image file 128 of a screen capture in theparent language could not typically simply be translated. Rather, a newimage file 138 of a screen capture of the same screen in the childlanguage would need to be taken. Thus, where an overall structure for PL120 was mirrored to the structure of CL 130, the particular image file128 could not simply be ported from its location in PIL 126 to thecorresponding location in CIL 136, but the re-shot image file 138 neededto be substituted into the location in the CIL. As language translationtools have improved, the text portion of the translation from PL 120 toCL 130 has been highly automated, applying a text translator to eachtext file 124 to create the corresponding text file 134 in the targetlanguage, and loading the translated text file 134 to the correspondinglocation in CTL 132. However, early knowledge base translation toolseither left the translation of the image content from PIL 126 to CIL 136as a manual task, or simply over-wrote CIL 136 with the content andstructure of PIL 126, leaving the decision as to whether to use the PILimages, or to again, manually reinsert the previously translated imagesinto the CIL. For example, if, in the original translation, where ascreen capture, GUI_Image1_en-usjpg was stored in PIL 126, a new screencapture could be recaptured as GUI_Image1_zh-cn.jpg and stored in theassociated location in CIL 136. However, when a change or revision to PL120 was performed, CIL 136 would typically be overwritten such that theCIL now included GUI_Image1_en-us.jpg instead of GUI_Image1_zh-cn.jpg,and the correct image would need to be manually reinserted into the CIL.This approach led to growing labor inputs to the maintenance ofknowledge bases, particularly where the PL was translated into multipleCLs, and only grew worse, as each update to the PL respawned anotherround of manual updates to ensure that the image content in the CILreflected the local language. For example, where a knowledge basearticle includes seven (7) locales each with one image, a modificationto the PL that includes a modified image will necessitate seven (7)modifications (one (1) to the PIL and six (6), one each, to the CILs).On the other hand, where a knowledge base article includes 23 localeseach with five images, a modification my necessitate up to 23*5=115edits to process image modifications.

As shown in FIG. 1 , each parent image 128 and its associated childimages 138 include metadata that is associated with the respectiveimage. In FIG. 2 , the metadata for parent image 128 and arepresentative child image 138 are shown. The metadata in each of parentimage 128 and child images 138 include information related to therelation between the associated PL 120 and the associated CLs 130. Inparticular, for each image, the metadata includes fields for: a GlobalUnique Identifier (GUID) for the image, an image file name, an imagedescription, an image category, an image version, an image locale, aparent image local GUID, one or more child image local GUID, an imagerepository file path, an image creation date, and an image last modifieddate. The image GUID represents a unique image identifier created withindatabase 100 for each image, and which are generated in accordance withan Internet Engineering Task Force (IETF) Standards-Track RFC 4122, orthe like. Here, parent image 128 includes a GUID value of “100” andchild image 139 includes a GUID value of “101.” Parent image 128 has afile name of “UI Element-EN” and is described as a “UI Dialog Box,” andchild image 138 has a file name of “UI Element-ZH” and is described as a“UI Dialog Box in Chinese.” Parent and child images 128 and 138 are eachdescribed as being in a “Support” category. The category field canassociate the respective images with a group or a type of knowledge basearticle, such as for a support knowledge base article, a servedknowledge base article, a sales or marketing knowledge base article, orother categories, as needed or desired. Parent image 128 is shown at aversion of “3.0,” and child image 138 is show at a version of “1.0.”Note that, as used with reference to FIG. 2 , and elsewhere, themetadata values provided are exemplary values, unless otherwiseindicated.

The remaining fields (the image locale, the parent image local GUID, thechild image local GUID, the image repository file path, the imagecreation date, and the image last modified date) are utilized increating, managing, and modifying the knowledge base, and particularlyin automating the update process, as described further below. Parentimage 128 has a locale of “EN-US” and child image 138 has a locale of“ZH-CN.” Here, the locale of any particular image can be provided as anISO 639 code associated with the language of any text within the image.For example, where child image 138 is identified with a locale value of“ZH-CN,” the child image is thus associated with a Simplified Chineselocale. Note that where a particular image includes no text, the localefield can be provided with an indicator associated with there being notext. For example, if there is no text in an image, the locale field cancarry a “NULL” value. Further in this example, where there is not textin an image, the parent image 128 and the child image 138 may have acommon GUID, but the other metadata fields may differ as indicated bythe needs of a parent image or a child image. For example, the file nameand description may differ, even though the GUID is the same. Parentimage 128 has a PIL GUID of “NULL” because there is no parent localassociated with the parent image. Parent image 128 further has a CILGUID of “101, 102, 103, 104, 105,” indicating that the parent image isassociated with child images in five (5) different CILs. Likewise, childimage 138 has a PIL GUID of “100” because it is associated with PIL 126,and has a CIL GUID of “NULL” because there are no associated CILs to CIL136. The repository fields include pointers to a location of therespective images, and can include a URL or the like that identifies alocation of the images. Here, parent image 128 includes a URL(image.repository.us) that is associated with English language images,and child image 138 includes a URL (image.repository.zh) that isassociated with Simplified Chinese language images. The created datefield indicates a date on which each particular image was created, andthe last modified date field indicates a date on which each particularimage was last modified.

FIG. 3 illustrates knowledge base 100 and the operations of a knowledgebase translator 300. Knowledge base translator 300 includes a texttranslator 310 and an image manager 320. Text translator 310 operates totranslate the text in each parent text file 124 into an associated childtext file 134. Text to text translation is known in the art and will notbe further described herein except as needed to illustrate the currentembodiments. Image manager 320 represents a rules-based engine fordetermining figures from PIL 128 and CIL 138 which should be utilized inupdating CL 130 in response to an update or change to PL 120. Inparticular, image manager 320 operates to determine if a CIL for aparticular CL exists. If not, then the images from the particular PILare rendered as the default images for the CL. In particular, when a newarticle is created in the parent language, the article will include aPIL with the associated parent image files. However, because the newarticle is yet to be translated, there is no associated CL, and hence noassociated CIL. In this case, when knowledge base translator 300translates the PL into a new CL. Here, text translator 310 translatesthe parent text files into associated child text files and arranges theminto a new CL. Further, image manager 320 operates to create a new CILin the CL, and to port the images from the PIL into the CIL. Here, imagemanager 320 operates to update the metadata fields in the child imagefiles as needed, but the image content may remain the same. For example,the image file name, the image description, the image category, theimage version, the image creation date, and the image last modified datemay remain unchanged. However, a new image GUID can be created becausethe image locale, the parent image local GUID, the child image GUID, andthe image repository file path are updated to reflect that the new imageis a child image to the parent image. In general, if the CIL exists,then the images in the CIL should be rendered as the default images forthe CL. However, if a particular parent image in the PIL has a newervalue in the last modified date field of the metadata than the value inthe last modified date field of the associated child image in the CIL,then the parent image is rendered in the CIL. Here, for example,consider where a PL of an article describing a user interface (UI) is inEnglish, and the CL of the article is in Japanese. When a change ormodification to the PL results in newer parent images of screen shots ofthe UI are modified into the PIL, the newer screen shots in Englishwould be more useful to show than the old screen shots with a wrong UI.That is, the right screen shot in a wrong language is better to bedisplayed in the CL than the wrong screen shot in the local language.Here, image manager 320 operates to indicate that the image from the PILwas rendered in place of the old image from the CIL. Here further, theindication can be used to identify the child images that need to bemanually updated, for example by taking screen shots of the appropriateUI pages in the local language. In any case, the translation of imagesfrom a PIL to an associated CIL may be overridden such that one or moreparticular images in the PIL are always rendered in the modified CIL, orsuch that one or more particular images in the CIL are always renderedin the CIL in spite of there being a newer associated image in the PIL,as needed or desired.

FIG. 4 illustrates a method for creating images in a knowledge base,starting at block 400. An image file is created in block 402. The imagefile may be understood broadly to include files and formats that cover awide range of visual content, audio content, or other content, as neededor desired. A decision is made as to whether or not the image filealready exists in a PIL or CIL of a Knowledge Base (KB) in decisionblock 404. If so, the “YES: branch of decision block 404 is taken, theexisting image file's metadata is updated with incremented versioninformation in block 406, with updated last modified date information inblock 408, with updated repository information if needed in block 410,and the method ends in block 412. If the image file does not alreadyexist in a PIL or CIL of a KB, the “NO” branch of decision block 404 istaken, a new image GUID is created in block 414, and the appropriateimage metadata is written for the image file in block 416. For example,the image file can be ascribed an image file name, an image description,an image category, an initial image version, an image locale, an imagerepository file path, an image creation date, and an image last modifieddate.

A decision is made as to whether or not the image file is ascribed as aparent image in decision block 418. That is, a decision is made as towhether or not the image file should be included in the PIL or in a CIL.If the image file is ascribed as a parent image, the “YES” branch ofdecision block 418 is taken, the parent image GUID field in the metadatais set to NULL in block 420, the child image GUID field is written withthe associated child image GUIDs in block 420, and the method ends inblock 412. If the image file is not ascribed as a parent image, the “NO”branch of decision block 418 is taken, the parent image GUID field inthe metadata is set to the associated parent image GUID in block 424,the child image GUID field is set to NULL in block 426, and the methodends in block 412.

FIG. 5 illustrates a method for updating a KB article, starting in block500. A KB article is selected for updating in block 502 and a decisionis made as to whether or not the KB is a new KB in block 504. If not,the “NO” branch of decision block 504 is taken, the KB article isupdated in block 506, the images are added to the KB article to theimage locale in block 508, and a decision is made as to whether or notthe KB article is localized in decision block 510. If not, the KBarticle is localized as described above in block 512, and the methodproceeds to block 520, as described further, below. If the KB article islocalized, the “YES” branch of decision block 510 is taken and themethod proceeds to block 520, as described further, below.

Returning to decision block 504, if the KB is a new KB, the “YES” branchis taken, the image metadata is updated in block 514, the images areadded to the KB article in block 516, the KB article is published inblock 518, and the method proceeds to block 520. In block 520, a call ismade for the KB image. A decision is made as to whether or not the imageexists for the locale in decision block 522. If not, the “NO” branch ofdecision block 522 is taken, the parent image is displayed in block 530,and the method ends in block 532. If the image exists for the locale,the “YES” branch of decision block 522 is taken and a decision is madeas to whether or not the image is a child image in decision block 524.If not, the “NO” branch of decision block 524 is taken, the parent imageis displayed in block 530, and the method ends in block 532. If theimage is a child image, the “YES” branch of decision block 524 is takenand a decision is made as to whether or not the child image is newerthan the parent image in decision block 526. If not, the “NO” branch ofdecision block 526 is taken, the parent image is displayed in block 530,and the method ends in block 532. If the child image is newer than theparent image, the “YES” branch of decision block 526 is taken, the childimage is displayed in block 528 and the method ends in block 532.

FIG. 6 illustrates a generalized embodiment of an information handlingsystem 600 similar to information handling systems 100 and 200. Forpurpose of this disclosure an information handling system can includeany instrumentality or aggregate of instrumentalities operable tocompute, classify, process, transmit, receive, retrieve, originate,switch, store, display, manifest, detect, record, reproduce, handle, orutilize any form of information, intelligence, or data for business,scientific, control, entertainment, or other purposes. For example,information handling system 600 can be a personal computer, a laptopcomputer, a smart phone, a tablet device or other consumer electronicdevice, a network server, a network storage device, a switch router orother network communication device, or any other suitable device and mayvary in size, shape, performance, functionality, and price. Further,information handling system 600 can include processing resources forexecuting machine-executable code, such as a central processing unit(CPU), a programmable logic array (PLA), an embedded device such as aSystem-on-a-Chip (SoC), or other control logic hardware. Informationhandling system 600 can also include one or more computer-readablemedium for storing machine-executable code, such as software or data.Additional components of information handling system 600 can include oneor more storage devices that can store machine-executable code, one ormore communications ports for communicating with external devices, andvarious input and output (I/O) devices, such as a keyboard, a mouse, anda video display. Information handling system 600 can also include one ormore buses operable to transmit information between the various hardwarecomponents.

Information handling system 600 can include devices or modules thatembody one or more of the devices or modules described below, andoperates to perform one or more of the methods described below.Information handling system 600 includes a processors 602 and 604, aninput/output (I/O) interface 610, memories 620 and 625, a graphicsinterface 630, a basic input and output system/universal extensiblefirmware interface (BIOS/UEFI) module 640, a disk controller 650, a harddisk drive (HDD) 654, an optical disk drive (ODD) 656 , a disk emulator660 connected to an external solid state drive (SSD) 662, an I/O bridge670, one or more add-on resources 674, a trusted platform module (TPM)676, a network interface 680, a management device 690, and a powersupply 695. Processors 602 and 604, I/O interface 610, memory 620,graphics interface 630, BIOS/UEFI module 640, disk controller 650, HDD654, ODD 656, disk emulator 660, SSD 662, I/O bridge 670, add-onresources 674, TPM 676, and network interface 680 operate together toprovide a host environment of information handling system 600 thatoperates to provide the data processing functionality of the informationhandling system. The host environment operates to executemachine-executable code, including platform BIOS/UEFI code, devicefirmware, operating system code, applications, programs, and the like,to perform the data processing tasks associated with informationhandling system 600.

In the host environment, processor 602 is connected to I/O interface 610via processor interface 606, and processor 604 is connected to the I/Ointerface via processor interface 608. Memory 620 is connected toprocessor 602 via a memory interface 622. Memory 625 is connected toprocessor 604 via a memory interface 627. Graphics interface 630 isconnected to I/O interface 610 via a graphics interface 632, andprovides a video display output 636 to a video display 634. In aparticular embodiment, information handling system 600 includes separatememories that are dedicated to each of processors 602 and 604 viaseparate memory interfaces. An example of memories 620 and 630 includerandom access memory (RAM) such as static RAM (SRAM), dynamic RAM(DRAM), non-volatile RAM (NV-RAM), or the like, read only memory (ROM),another type of memory, or a combination thereof.

BIOS/UEFI module 640, disk controller 650, and I/O bridge 670 areconnected to I/O interface 610 via an I/O channel 612. An example of I/Ochannel 612 includes a Peripheral Component Interconnect (PCI)interface, a PCI-Extended (PCI-X) interface, a high-speed PCI-Express(PCIe) interface, another industry standard or proprietary communicationinterface, or a combination thereof. I/O interface 610 can also includeone or more other I/O interfaces, including an Industry StandardArchitecture (ISA) interface, a Small Computer Serial Interface (SCSI)interface, an Inter-Integrated Circuit (I²C) interface, a System PacketInterface (SPI), a Universal Serial Bus (USB), another interface, or acombination thereof. BIOS/UEFI module 640 includes BIOS/UEFI codeoperable to detect resources within information handling system 600, toprovide drivers for the resources, initialize the resources, and accessthe resources. BIOS/UEFI module 640 includes code that operates todetect resources within information handling system 600, to providedrivers for the resources, to initialize the resources, and to accessthe resources.

Disk controller 650 includes a disk interface 652 that connects the diskcontroller to HDD 654, to ODD 656, and to disk emulator 660. An exampleof disk interface 652 includes an Integrated Drive Electronics (IDE)interface, an Advanced Technology Attachment (ATA) such as a parallelATA (PATA) interface or a serial ATA (SATA) interface, a SCSI interface,a USB interface, a proprietary interface, or a combination thereof. Diskemulator 660 permits SSD 664 to be connected to information handlingsystem 600 via an external interface 662. An example of externalinterface 662 includes a USB interface, an IEEE 1394 (Firewire®)interface, a proprietary interface, or a combination thereofAlternatively, solid-state drive 664 can be disposed within informationhandling system 600.

I/O bridge 670 includes a peripheral interface 672 that connects the I/Obridge to add-on resource 674, to TPM 676, and to network interface 680.Peripheral interface 672 can be the same type of interface as I/Ochannel 612, or can be a different type of interface. As such, I/Obridge 670 extends the capacity of I/O channel 612 when peripheralinterface 672 and the I/O channel are of the same type, and the I/Obridge translates information from a format suitable to the I/O channelto a format suitable to the peripheral channel 672 when they are of adifferent type. Add-on resource 674 can include a data storage system,an additional graphics interface, a network interface card (NIC), asound/video processing card, another add-on resource, or a combinationthereof. Add-on resource 674 can be on a main circuit board, on separatecircuit board or add-in card disposed within information handling system600, a device that is external to the information handling system, or acombination thereof.

Network interface 680 represents a NIC disposed within informationhandling system 600, on a main circuit board of the information handlingsystem, integrated onto another component such as I/O interface 610, inanother suitable location, or a combination thereof. Network interfacedevice 680 includes network channels 682 and 684 that provide interfacesto devices that are external to information handling system 600. In aparticular embodiment, network channels 682 and 684 are of a differenttype than peripheral channel 672 and network interface 680 translatesinformation from a format suitable to the peripheral channel to a formatsuitable to external devices. An example of network channels 682 and 684includes InfiniBand® channels, Fibre Channel channels, Gigabit Ethernetchannels, proprietary channel architectures, or a combination thereof.Network channels 682 and 684 can be connected to external networkresources (not illustrated). The network resource can include anotherinformation handling system, a data storage system, another network, agrid management system, another suitable resource, or a combinationthereof.

Management device 690 represents one or more processing devices, such asa dedicated baseboard management controller (BMC) System-on-a-Chip (SoC)device, one or more associated memory devices, one or more networkinterface devices, a complex programmable logic device (CPLD), and thelike, that operate together to provide the management environment forinformation handling system 600. In particular, management device 690 isconnected to various components of the host environment via variousinternal communication interfaces, such as a Low Pin Count (LPC)interface, an Inter-Integrated-Circuit (I2C) interface, a PCIeinterface, or the like, to provide an out-of-band (OOB) mechanism toretrieve information related to the operation of the host environment,to provide BIOS/UEFI or system firmware updates, to managenon-processing components of information handling system 600, such assystem cooling fans and power supplies. Management device 690 caninclude a network connection to an external management system, and themanagement device can communicate with the management system to reportstatus information for information handling system 600, to receiveBIOS/UEFI or system firmware updates, or to perform other task formanaging and controlling the operation of information handling system600. Management device 690 can operate off of a separate power planefrom the components of the host environment so that the managementdevice receives power to manage information handling system 600 when theinformation handling system is otherwise shut down. An example ofmanagement device 690 include a commercially available BMC product orother device that operates in accordance with an Intelligent PlatformManagement Initiative (IPMI) specification, a Web Services Management(WSMan) interface, a Redfish® Application Programming Interface (API),another Distributed Management Task Force (DMTF), or other managementstandard, and can include an Integrated Dell® Remote Access Controller(iDRAC), an Embedded Controller (EC), or the like. Management device 690may further include associated memory devices, logic devices, securitydevices, or the like, as needed or desired.

Although only a few exemplary embodiments have been described in detailherein, those skilled in the art will readily appreciate that manymodifications are possible in the exemplary embodiments withoutmaterially departing from the novel teachings and advantages of theembodiments of the present disclosure. Accordingly, all suchmodifications are intended to be included within the scope of theembodiments of the present disclosure as defined in the followingclaims. In the claims, means-plus-function clauses are intended to coverthe structures described herein as performing the recited function andnot only structural equivalents, but also equivalent structures.

The above-disclosed subject matter is to be considered illustrative, andnot restrictive, and the appended claims are intended to cover any andall such modifications, enhancements, and other embodiments that fallwithin the scope of the present invention. Thus, to the maximum extentallowed by law, the scope of the present invention is to be determinedby the broadest permissible interpretation of the following claims andtheir equivalents, and shall not be restricted or limited by theforegoing detailed description.

What is claimed is:
 1. An information handling system, comprising: amemory device to store machine executable code; and a processor toexecute the machine executable code, the processor configured to:instantiate a knowledge base including knowledge base informationarranged into a parent image locale (PIL) that includes a first parentimage that presents a first portion of the knowledge base information ina first language, and a second parent image that presents a secondportion of the knowledge base information; and translate the knowledgebase information into a second language, wherein in translating theknowledge base information, the processor is further configured to:determine that the knowledge base information has previously beentranslated into the second language based upon the knowledge baseinformation being further arranged into a child image locale (CIL) thatincludes a first child image that presents the first portion of theknowledge base information in the second language, and a second childimage that presents the second portion of the knowledge baseinformation; replace the first child image with the first parent imagein the CIL when a first date when the first parent image was modified islater than a second date when the first child image was modified; andretain the second child image in the CIL when a first globally uniqueidentifier (GUID) of the second parent image is the same as a secondGIUD of the second child image.
 2. The information handling system ofclaim 1, wherein in translating the knowledge base information, theprocessor is further configured to: retain the first child image in theCIL when the first date is earlier than the second date.
 3. Theinformation handling system of claim 1, wherein in translating theknowledge base information, the processor is further configured to:determine that the knowledge base information has not been previouslytranslated into the second language based upon the knowledge baseinformation not being further arranged into the CIL; create the CIL inthe knowledge base in response to determining that the knowledge baseinformation has not been previously translated into the second language;and store the first parent image in the CIL.
 4. The information handlingsystem of claim 1, wherein: the first parent image includes firstmetadata that includes a third GUID associated with the first parentimage; and in determining that the knowledge base information haspreviously been translated into the second language, the processor isfurther configured to determine that the first metadata includes afourth GUID associated with the first child image.
 5. The informationhandling system of claim 4, wherein the first metadata further includesthe first date; second metadata included in the first child imageincludes the second date; and in determining whether the first date islater than the second date, the processor is further configured to: readthe first metadata from the first parent image; read the second metadatafrom the first child image; and compare the first date from the firstmetadata with the second date from the second metadata.
 6. Theinformation handling system of claim 5, wherein the first metadatafurther includes a first parent field that is stored with a null value,and a first child field that is stored with the fourth GUID.
 7. Theinformation handling system of claim 6, wherein the second metadatafurther includes a second parent field that is stored with the thirdGUID, and a second child field that is stored with the null value. 8.The information handling system of claim 5, wherein the first metadatafurther includes a first code associated with the first language, andthe second metadata further includes a second code associated with thesecond language.
 9. The information handling system of claim 8, whereinthe first and the second codes encode the respective first and secondlanguages in accordance with an ISO 639 language code.
 10. A method formanaging images in a knowledge base on an information handling system,the method comprising: instantiating, by a processor of the informationhandling system, the knowledge base, the knowledge base includingknowledge base information arranged into a parent image locale (PIL)that includes a first parent image that presents a first portion of theknowledge base information in a first language; translating theknowledge base information into a second language, wherein intranslating the knowledge base information, the processor is furtherconfigured to: determine that the knowledge base information haspreviously been translated into the second language based upon theknowledge base information being further arranged into a child imagelocale (CIL) that includes a first child image that presents the firstportion of the knowledge base information in the second language;replace the first child image with the first parent image in the CILwhen a first date when the first parent image was modified is later thana second date when the first child image was modified; and retain thesecond child image in the CIL when a first globally unique identifier(GUID) of the second parent image is the same as a second GIUD of thesecond child image.
 11. The method of claim 10, wherein in translatingthe knowledge base information, the method further comprises: retainingthe first child image in the CIL when the first date is earlier than thesecond date.
 12. The method of claim 10, wherein in translating theknowledge base information, the method further comprises: determiningthat the knowledge base information has not been previously translatedinto the second language based upon the knowledge base information notbeing further arranged into the CIL; creating the CIL in the knowledgebase in response to determining that the knowledge base information hasnot been previously translated into the second language; and storing thefirst parent image in the CIL.
 13. The method of claim 10, wherein: thefirst parent image includes first metadata that includes the first GUIDassociated with the first parent image; and in determining that theknowledge base information has previously been translated into thesecond language, the method further comprises determining that the firstmetadata includes the second GUID.
 14. The method of claim 13, whereinthe first metadata further includes the first date; second metadataincluded in the first child image includes the second date; and indetermining whether the first date is later than the second date, themethod further comprises: reading the first metadata from the firstparent image; reading the second metadata from the first child image;and comparing the first date from the first metadata with the seconddate from the second metadata.
 15. The method of claim 14, wherein thefirst metadata further includes a first parent field that is stored witha null value, and a first child field that is stored with the secondGUID.
 16. The method of claim 15, wherein the second metadata furtherincludes a second parent field that is stored with the first GUID, and asecond child field that is stored with the null value.
 17. The method ofclaim 14, wherein the first metadata further includes a first codeassociated with the first language, and the second metadata furtherincludes a second code associated with the second language.
 18. Themethod of claim 17, wherein the first and the second codes encode therespective first and second languages in accordance with an ISO 639language code.
 19. An information handling system, comprising: a memory;and a processor in communication with the memory and configured to:instantiate a knowledge base including knowledge base informationarranged into: a parent text locale (PTL) that includes a parent textfile that presents a first portion of the knowledge base information ina first language; and a parent image locale (PIL) that includes a firstparent image file that presents a second portion of the knowledge baseinformation in the first language and a second parent image file thatpresents a third portion of the knowledge base information; andtranslate the knowledge base information into a second language, whereinin translating the knowledge base information, the processor is furtherconfigured to: determine that the knowledge base information haspreviously been translated into the second language based upon theknowledge base information being further arranged into: a child textlocale (CTL) that includes a child text file that presents the firstportion of the knowledge base information in the second language; and achild image locale (CIL) that includes a first child image file thatpresents the second portion of the knowledge base information in thesecond language, and a second child image that presents the thirdportion of the knowledge base; translate the parent text file to arevised child text file; replace the child text file with the revisedchild text file in the CTL; and replace the first child image with thefirst parent image in the CIL when a first date when the first parentimage was modified is later than a second date when the first childimage was modified; and retain the third child image in the CIL when afirst globally unique identifier (GUID) of the third parent image is thesame as a second GIUD of the third child image.
 20. The informationhandling system of claim 19, wherein in translating the knowledge baseinformation, the processor is further configured to: retain the firstchild image in the CIL when the first date is earlier than the seconddate.